1. Field of the Invention
The present invention relates to a method of setting up a protection path for restoring a link or node failure on a working path established in a network, and an apparatus for implementing the method.
With the widespread use of the Internet in recent years, the demand for high transmission efficiency and quality has been increasing. To achieve this, a technology for superimposing IP packets on a physical link with the smallest possible overhead (for example, IP over DWDM (Dense WDM)) and Multi Protocol Label Switching (MPLS) as a means for achieving low-cost and high-speed transmission of IP packets at the hardware level have been attracting attention. In these circumstances, since the protection that has traditionally been provided at a lower layer such as SONET/SDH can no longer be provided, packet protection, a scheme for providing protection at a higher layer, is needed.
2. Description of the Related Art
In this era where the IP packet is recognized as a basic transmission unit, there is a tendency for lower layers such as SDH/SONET to be rendered unnecessary and, for failure restoration in a network, packet protection, a scheme for accomplishing restoration on a packet-by-packet basis, has been receiving attention.
In packet protection, a protection switch node (hereinafter abbreviated PSL) and a protection merge node (hereinafter abbreviated PML) are determined on a working path, and a different path that does not overlap with the working path is set up from the PSL to the PML. If a failure occurs along the segment between the PSL and PML on the working path, a node that has detected the failure sends a failure notification to the PSL which then reroutes the traffic over the protection path. There are no provisions for the number of links between the PSL and PML (the range of failure to be restored by one protection path), and various repair schemes such as global repair and local repair are currently being proposed. However, the method of implementing the packet protection, including the method of determining the PSL and PML on the working path, the method of setting up the protection path, and the method of switching, has not yet been clearly defined.
Among the various repair schemes currently proposed, local repair, in which a node that detects a failure or its adjacent node performs switching to the protection path, is attracting particular attention because of its capability to accomplish switching within 50 ms and its simple mechanism.
As a method of implementing such packet protection, a path protection method using MPLS that enables high-speed packet forwarding is described in a document presented to IETF by Tellabs (draft-change-mpls-rsvpte-path-protection-00.txt, draft-change-mpls-rsvptepath-protection-01.txt).
In this document, the following provisions for achieving faster switching to a protection path are described without limiting the repair scheme to any particular method.
For protection path setup, it is recommended that a protection path be set up in advance in order to reduce the switching time. In a specific method of path setup, the PSL on the working path determines the PML from among the downstream nodes on the working path, and determines the route of the protection path in accordance with a path selection algorithm in such a manner that the protection path does not overlap with the working path between the PSL and PML. The PML merges the outgoing end of the protection path into an outgoing path of the corresponding working path. It is specified that the protection path thus set up be required to satisfy the same QoS requirements (bandwidth and delay requirements) as the corresponding working path.
The switchover from the working to the protection path is initiated by sending a failure notification from a downstream node that has detected the failure to the PSL located on the upstream side. High priority is given to the failure notification. Each node extracts the destination of the failure notification based on the RNT created in advance during the establishment of the path, and performs label switching by using an inverse-cross-connect table. This, as it is proposed in the document, contributes to speeding up the notification of a failure and reducing the switching time.
To provide packet protection, it is required that the same bandwidth as that for the working path be guaranteed for its protection path through which no traffic flows before protection switching. If the same bandwidth is to be reserved not only for the working path but also for its protection path, the total number of paths required in the entire network increases as the PSL to PML distance becomes shorter, and more than twice the bandwidth of the working path will become necessary for the network as a whole, reducing the efficiency of network resource utilization. Accordingly, for the realization of packet protection, it is becoming important to also consider a “bandwidth sharing scheme” which aims at saving network resources by sharing the bandwidth among protection paths, but this scheme is difficult to implement; in fact, the method proposed by Tellabs only describes the following condition and does not provide any specific method of implementation.
The condition for bandwidth sharing: Protection paths provided for a plurality of working paths that do not share any nodes between PSL and PML can share the bandwidth (since the bandwidth will not become necessary simultaneously if the occurrence of a double failure is not considered). The shared protection path bandwidth must be equal to the maximum of the bandwidths in the plurality of corresponding paths.
Japanese Patent No. 2985940 discloses a method in which, when establishing a working path in a large-scale network, complete source route information of the working path is acquired by the ingress node of the path in order to set up a protection route and, when setting up a protection path, the source route information is added to signaling information for connection setup, thereby setting up a physical path entirely different from the working path. With this method, however, when a failure occurs, the failure must be reported all the way to the ingress node; this not only takes time to switch to the protection path, but ends up being unable to guarantee the same QoS (bandwidth and delay) as that for the working path when the path is switched to the protection path.
The protection scheme presented by Tellabs only describes the path setup conditions. When the protection path is set up manually in accordance with the conditions, working/protection switchover can be accomplished within the required time, i.e., 50 ms, but the problem is that everything has to be managed manually, requiring an enormous number of maintenance cost.
Furthermore, though the protection scheme is described on the premise that the PSL recognizes the topology up to the PML, if this scheme is applied in a large-scale network that uses the concept of “area”, control may not be able to be performed because a node in a certain area cannot recognize the topology outside the area. For example, when setting up a protection path bypassing an area border node, the proposed scheme has the problem that the PSL cannot determine a node outside the area as the PML, nor can a route be selected that does not overlap with the working path. In this case, the path can be set up if maintenance personnel explicitly specify the protection path route, but there is a limit to the kinds of topologies that maintenance personnel can recognize and, as one can easily imagine, they are prone to error.
As for the protection path delay guarantee, the end-to-end delay when routed via the protection path must be guaranteed. The problem here is that with the PSL-to-PML delay information alone, it is not possible to guarantee the end-to-end delay, and the scheme proposed by Tellabs does not provide any specific means to address this issue.